REMARKS/ ARGUMENTS 



Claims 1-89 are pending in the present application. Claims 1, 3-4, 6-7, 1 1, 22, 24, 33, 44-46, 60- 
62, and 76-78 have been amended. Claims 87-89 have been canceled; and claims 90-92 have been newly 
added. Support of the newly added claims can be found in the original claims 4-6 and in the Specification 
at least on p. 16, 11. 23-30 and in Figures 3A and 3B. Reconsideration of the claims is respectfully 
requested. 

An amendment allegedly filed on October 29, 2004 is referenced in the present Office Action 
dated December 29, 2004. However, Applicants' records and the records on USPTO PAIR show the last 
item filed by Applicants prior to the present the Office Action was a response to a previous Office Action, 
filed on September 13, 2004. Consequently, the present response is based on the December 29, 2004 
Office Action and the September 13, 2004 Response to Office Action. The Examiner is requested to 
provide Applicants with a copy of the amendments allegedly filed on October 29, 2004 and considered by 
the Examiner. 



I. 35 U.S.C. § 112. First Paragraph 

The Examiner has rejected claims 1 -89 under 35 U.S.C. § 1 1 2, first paragraph, alleging that the 
claims fail to comply with the written description requirement. This rejection is respectfully traversed. 

I.A. As to independent claims 1 and 4 

The Examiner states: 

Claims 1-89 are rejected under 35 U.S.C. 112, first paragraph, as failing 
to comply with the written description requirement. The claim(s) contains 
subject matter which was not described in the specification in such a way as to 
reasonably convey to one skilled in the relevant art that the inventor(s), at the 
time the application was filed, had possession of the claimed invention. 

Referring to Claims 1 & 4, where in the specification does the applicant 
define the limitation "wherein the target address has been related to and stored in 
the table entry based on a computer value from a relation computation using the 
table index and the target address as operands in the relation computation" 

The specification discloses that the target object can be determined based 
upon a computed or mathematical relationship between the target index and the 
target identifier or in other words target object=mathematical relation (SID, 
index, target id) on Pg 7 line 1-Pg 8 line 15. 

The specification provides written support that the target id can be 
determined based upon a computed or mathematical relationship with the SID 
and target index or in other words target id-relation (SID, index) per Pg 2 line 20- 
Pg 3 line 24. 
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The applicant has claimed target address=mathematical relation (target 
address, target index) which is not defined in the specification. 

Office Action dated December 29, 2004, pp. 13-14. 

Independent claim 1 is as follows: 

1 . A router comprising: 
a computer readable medium; 

a plurality of transmission links for receiving and sending data; 

retrieving means for retrieving a destination address from a data packet; 

hashing means for hashing the destination address to determine a table 
index into a table; 

reading means for reading a target address from a table entry using the 
table index, wherein the target address has been related to and stored in the table 
entry based on a computed value from a relation computation using the table 
index and the target address as operands in the relation computation; and 

modifying means for modifying the data packet by storing the target 
address in the data packet as a next-hop destination address. 

The Examiner incorrectly rejects the feature "wherein the target address has been related to and 
stored in the table entry based on a computed value from a relation computation using the table index and 
the target address as operands in the relation computation" of claim 1 , (hereinafter the "wherein feature"), 
stating incorrectly that the feature does not have adequate support in the specification. The specification 
provides: 

TargetMap table 312 has a number of entries that may be accessed by an 
index into the table. The number of entries in targetMap table 312 and the 
number of targets in target set 302 may vary from several to many thousand 
depending upon the application. The targetMap table is of fixed but configurable 
length and is generally specified to have a length that is larger than the number of 
targets by a small factor, e-g., the number of entries in the targetMap may be four 
times the number of targets in the target set. 

Each entry of the targetMap will be associated or related with a single 
target from the target set. For example, an entry could contain: a target identifier; 
information associated with a target; a pointer to information concerning a target; 
or some other type of data for associating or relating a particular target with a 
particular entry. 

Specification, p. 16, 11. 7-18. 

This section of the specification is one exemplary section in the specification that lends full 
support to the wherein feature. Here, the specification provides that each entry in the TargetMap table is 
accessible by an index into the table. This part provides support for the term "table index" used in the 
wherein feature. 

Next, the above section of the specification provides that each entry of the TargetMap will be 
" associated or related with a single target " from the target set. The specification thus provides necessary 
support for the term "related to" as used in the wherein feature. The specification recites "associated or 
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related" indicating that "related with" is the same as "associated with". Consistent with the wherein 
feature in claim 1, and lending adequate support thereto, the specification further provides that the 
association of a target is with an entry in the table. The specification also provides through examples that 
an entry could contain an "information associated with a target". A target address is an information 
associated with a target. Thus, the specification fully supports the term "target address" as used in the 
wherein feature of claim 1 . 

Therefore, at least the above cited section of the specification provides adequate support to the 
wherein feature rejected by the examiner. Thus, the feature "wherein the target address has been related 
to and stored in the table entry based on a computed value from a relation computation using the table 
index and the target address as operands in the relation computation" of claim 1 has a definite meaning 
supported by the specification. Therefore, claim 1 meets the written description requirement of 35 U.S.C. 
§ 1 12, first paragraph. 

Furthermore, the Examiner has drawn incorrect conclusions from the description provided in the 
specification. On the one hand, the Examiner concedes, "[t]he specification discloses that the target 
object can be determined based upon a computed or mathematical relationship . . .", and on the other hand 
the Examiner states, "... in other words, target object=mathematical relationship". If a value, here the 
target object, is determined based upon a mathematical relationship, the value does not become the 
mathematical relationship itself. A value is distinct from the way the value is computed, such as by using 
a mathematical relationship, for example, a mathematical function. Therefore, the examiner's statement 
as to the provisions of the specification is correct, but the examiner's conclusion as to the target object is 
wrong. 

Claim 4 contains features similar to those in claim 1, including the wherein feature. Therefore, 
by similar reasoning as above, the rejection of claim 4 has also been overcome. Therefore, the rejection 
of claims 1-6 under 35 U.S.C. § 1 12, first paragraph, has been overcome. 

New claims 90-92 contain features similar to claims 4-6 and further clarify the term "relation 
computation" in accordance with the specification (Specification, p. 16, 11. 23-30; Figures 3A-3B). 
Therefore, claims 90-92 also contain patentable subject matter under 35 U.S.C. § 1 12, first paragraph. 

I.B. As to independent claims 9, 20. 31, 42, 58, and 74 

Independent claim 9 contains a different feature that the Examiner has used for the basis of 

rejection under 35 U.S.C. § 1 12, first paragraph. The Examiner states: 

Referring to Claims 9, 20, 31, 42, 58, & 74, where in the specification 
does the applicant define the limitation "wherein the target identified has been 
related to and stored in the table entry based on a computed value from a relation 
computation using the table index and the target identifier as operands in the 
relation computation 
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The specification discloses that the target object can be determined based 
upon a computed or mathematical relationship between the target index and the 
target identifier or in other words target object=mathematical relation (SID, 
index, target id) on Pg 7 line 1-Pg 8 line 15. 

The specification discloses that the target id can be determined based 
upon a computed or mathematical relationship with the SID and target index or 
in other words target id-relation (SID, index) per Pg 2 line 20-Pg 3 line 24. 

The applicant has claimed target identifier=mathematical relation (target 
id, table index) which is not defined in the specification. 

Office Action dated December 29, 2004, p. 14. 
Claim 9 recites: 

9. A method in a data processing system for mapping a source 
identifier to a target identifier, the method comprising the steps of: 

hashing the source identifier to determine a table index into a table in a 
computer readable medium; and 

reading the target identifier from a table entry using the table index, 
wherein the target identifier has been related to and stored in the table entry 
based on a computed value from a relation computation using the table index and 
the target identifier as operands in the relation computation. 

The Examiner incorrectly rejects the feature "wherein the target identifier has been related to and 
stored in the table entry based on a computed value from a relation computation using the table index and 
the target identifier as operands in the relation computation" of claim 9, (hereinafter the "wherein feature 
of claim 9"), stating incorrectly that the feature does not have adequate support in the specification. 

The wherein feature of claim 9 differs from the wherein feature of claim 1 in that where the 
wherein feature of claim 1 recites "target address " the wherein feature of claim 9 recites "target 
identifier ". Therefore, the same section of the specification described above lends full support to the 
wherein feature of claim 9 in the manner described above. Furthermore, that section of the specification 
specifically provides that an entry could contain "a target identifier", providing additional support of the 
distinction between the wherein feature of claim 9 and the wherein feature of claim 1 . 

Thus, the feature "wherein the target identifier has been related to and stored in the table entry 
based on a computed value from a relation computation using the table index and the target identifier as 
operands in the relation computation" of claim 9 has a definite meaning supported by the specification. 
Independent claims 20, 31, 42, 58, and 74 contain features similar to those in claim 9 and are also fully 
supported by the specification by similar reasoning. Therefore, the rejection as to claims 9-86 under 35 
U.S.C. § 1 12, first paragraph, has been overcome. Rejection of claims 87-89 is moot in view of 
cancellation of those claims. 
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I.C. As to independent claim 7 

The Examiner has rejected claims 7-8 in rejecting claims 1-89 under 35 U.S.C. § 112, first 
paragraph. However, claims 7-8, of which claim 7 is an independent claim, do not contain the feature that 
is the subject of the examiner's rejection, and appear to have been included for the purpose of rejecting 
the entire set of claims. Thus, the rejection of claims 7-8 under 35 U.S.C. § 1 12, first paragraph lacks 
sufficient grounds for the rejection, and should be withdrawn. 

I.D. As to dependent claims 14, 25, 36. 47, 63. and 79 

Claim 14 recites: 

1 4. The method of claim 9 wherein the relation computation further 
comprises: 

receiving the table index and the target identifier as operands for the 
relation computation; 

hashing the table index to generate a first hash value; 

hashing the target identifier to generate a second hash value; and 

hashing the first hash value and the second hash value to generate a 
computed value. 

The Examiner states: 

Referring to Claims 14,25,36,47, 63, & 79, where in the specification 
does the applicant define the limitation ""receiving the table index and the target 
identifier as operands for the relation computation; hashing the table index to 
generate a first has value; hashing the target identifier to generate a second has 
value; and hashing the first hash value and the second has value to generate a 
computed value"? 

Office Action dated December 29, 2004, p. 14. 

In response, the examiner's attention is directed to Figure 6, particularly to reference 
numerals 610, 612, 614, 616, 618, and 620. Figure 6 is reproduced below for convenience: 
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Figure 6 

Specification, Figure 6. 

Corresponding description is provided in the specification as follows: 

Nearness function 600 accepts target identifiers 601-605 and targetMap 
index 608, which are inputted into hash function 610 and hash function 612, 
respectively. Hash function 610 produces a set of hash values 614, while hash 
function 612 produces hash value 616. Each hash value 614 is generated from a 
single target identifier as input to hash function 610. Each hash value 614 is then 
separately hashed together with hash value 616 by hash function 618, which 
produces a single nearness value. After executing hash function 618 for each 
hash value 614, a set of nearness values 620 is produced. Nearness values 620 
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are then compared to each other by comparator 622 to determine nearness value 
624, which is a single nearness value generated from using one of the target 
identifiers 601-605 as an input. 

Specification, p. 30, 11. 9-23. 

The above Figure and specification section are self-explanatory and correspond to the features of 
claim 14 that the Examiner calls into question. In addition, a claim can be fully supported by the claim 
language itself as originally filed for the purposes of written description requirement of § 112, first 
paragraph. This condition is also satisfied by claim 14 in its present form. Thus, adequate support for 
claims 14, 25, 36, 47, 63, and 79 is present in the specification to meet the written description requirement 
under 35 U.S.C. § 1 12, first paragraph. 

I.E. As to dependent claims 18. 29. 40, 56, 72, and 88 

Claim 1 8 recites: 

1 8. The method of claim 9 wherein the target identifier is a network 
physical address. 

The Examiner states: 

Referring to Claims 18, 29, 40, 56, 72 & 88, where in the specification 
does the applicant define the limitation that the target identifier is a network 
physical address? Does the applicant mean that the next hop address is the 
network physical address in which case the applicant means that the network 
physical address is a target object and not a target identifier. 

Office Action dated December 29, 2004, pp. 14-15. 

In response, the examiner's attention is directed to the specification as follows: 

A target identifier may be a number, an ASCII string, a name, or some 
other form of identifier by which the target is uniquely identifiable. 

Specification, p. 20, 11. 1 1-13. 

The above exemplary section of the specification is self-explanatory, and corresponds to the 
features of claim 19 that the Examiner calls into question. A network physical address of a target is a 
form of identifier by which a target is uniquely identifiable as provided in the specification. In addition, a 
claim can be fully supported by the claim language itself as originally filed for the purposes of written 
description requirement of § 112, first paragraph. This condition is also satisfied by claim 18 in its 
present form. Thus adequate support for claims 18, 29, 40, 56, and 72 is present in the specification to 
meet the written description requirement under 35 U.S.C. § 112, first paragraph. Rejection of claim 88 is 
moot in view of the cancellation of claim 88. 
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I F. As to dependent claims 19, 30. 41. 57. 73. and 89 

Claim 19 recites: 

1 9. The method of claim 9 wherein the target identifier is a Uniform 
Resource Identifier (URI). 

The Examiner states: 

Referring to Claim 19, 30, 41, 57, 73, & 89, where in the specification 
does the applicant define the limitation that the target identifier is the Uniform 
Resource Identifier? On Page 1 3 line 1 8 the applicant specifies a requesting a 
URL address which implies that the address is a destination address and not a 
target identifier) 

Office Action dated December 29, 2004, p. 15. 

In response, the examiner's attention is directed to the specification as follows: 

Key 320, which represents some type of identifier from a source object, 
such as a URL, is input into the stable hash computation process. Key 320 is 
input into hash function 322, which produces hash code 324. The hash code is 
used as an index into an entry in targetMap 302, and the targetMap entry 
specifies its associated target, which is target 310 in this example. 

Specification, p. 19, 11. 6-12. 

The above exemplary section of the specification is self-explanatory, and corresponds to the 
features of claim 1 9 that the Examiner calls into question. In addition, a claim can be fully supported by 
the claim language itself as originally filed for the purposes of written description requirement of § 112, 
first paragraph. This condition is also satisfied by claim 19 in its present form. Thus adequate support for 
claims 19, 30, 41, 57, and 73 is present in the specification to meet the written description requirement 
under 35 U.S.C. § 1 12, first paragraph. Rejection of claim 89 is moot in view of the cancellation of claim 
89. 

LG. As to dependent claims 54. 70. and 86 

Claim 54 recites: 

54. The method of claim 42 wherein the data structure is a table, and 
the location identifier is a table index. 

The Examiner states: 

Referring to Claims 54, 70, & 86, where in the specification does the 
applicant define the limitation that a location identifier is a table index? 

Office Action dated December 29, 2004, p. 15. 

In response, the examiner's attention is directed to the specification as follows: 

Alternatively, hash function 322 may be replaced by some other type of 
computation, function, or lookup operation that maps, converts, or transforms 
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key 320 to a location within the targetMap data structure as long the replacement 
functionality is similar to a hash function. The intention is that the input key is 
quickly and efficiently mapped, converted, or transformed to a data structure 
location with a fair and determinative distribution of input values across the data 
structure locations in a manner similar to a hash function. 

Specification, p. 19, 11. 13-22. 

The above exemplary section of the specification is self-explanatory, and corresponds to the 
features of claim 54 that the Examiner calls into question. For example, if the hash function 322 is 
replaced by a mapping function as the specification section provides, key 320, which can be a location 
identifier, maps to a location, i.e. index, within the targetMap. This description is supported by the 
following Figure: 




Figure 3E 

Specification, Figure 3E. 

The above exemplary description of the specification section in conjunction with Figure 3E of the 
original specification fully supports the features of claim 54. In addition, a claim can be fully supported 
by the claim language itself as originally filed for the purposes of written description requirement of § 
112, first paragraph. This condition is also satisfied by claim 19 in its present form. Thus, adequate 
support for claims 19, 30, 41, 57, 73, and 89 is present in the specification to meet the written description 
requirement under 35 U.S.C. § 1 12, first paragraph. 

II. 35 U.S.C. § 112, Second Paragraph 

The Examiner has rejected claims 1-89 under 35 U.S.C. § 1 12, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter, which applicants 
regard as the invention. This rejection is respectfully traversed. 
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The Examiner states: 

Claims 1-89 are rejected under 35 U.S.C. 112, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the 
subject matter which applicant regards as the invention. 

Referring to Claims 1 & 4, What is meant by the limitation "wherein the 
target address has been related to and stored in the table entry based on a 
computer value from a relation computation using the table index and the target 
address as operands in the relation computation"; consequently, the examiner 
cannot assess the metes and bounds of the claims. 

Referring to Claims 9, 20, 31, 42, 58, & 74, What is meant by the 
limitation "wherein the target identified has been related to and stored in the table 
entry based on a computed value from a relation computation using the table 
index and the target identifier as operands in the relation computation"; 
consequently, the examiner cannot assess the metes and bounds of the claims. 

Office Action dated December 29, 2004, p. 1 5. 

This rejection of claims 1-89 is subdivided in a manner similar to the rejection of claims 1-89 
under 35 U.S.C. § 1 12, first paragraph, that has been addressed above. The feature in claims 1 -6 that is 
the subject of rejection under § 1 12, second paragraph is the same as the feature that formed the basis of 
rejection of the same set of claims under § 1 12, first paragraph, namely, the wherein feature of claim 1 . 
Similarly, the feature in claims 9-89 that is the subject of rejection under § 1 1 2, second paragraph is the 
same as the feature that formed the basis of rejection of the same set of claims under § 1 12, first 
paragraph, namely, the wherein feature of claim 9. Claims 7-8, although included in the rejection under § 
1 1 2, second paragraph, again lack the feature that is the subject of this rejection. 

The rejection of claims 1 -89 under § 1 1 2, second paragraph, is also overcome by the support 
found in the specification, and reasoning based thereon provided in response to the rejection under § 1 12, 
first paragraph, above. Thus, the "metes and bounds of the claims" as desired by the Examiner are 
adequately clarified by interpreting the claims in light of the specification, and particularly in light of the 
exemplary section of the specification quoted above. Therefore, the rejection of claims 1-6 and 9-86 
under 35 U.S.C. § 1 12, second paragraph has been overcome, and the rejection of claims 7-8 should be 
withdrawn. Rejection of claims 87-89 is moot in view of the cancellation of those claims. 



III. 35 U.S.C. § 103, Obviousness 

III.A. As to claims 1-6 

The Examiner has rejected claims 1-6 under 35 U.S.C. § 103(a) as being unpatentable over 
Munter et al., Address Translation Method and System Having a Forwarding Table Data Structure , 
United States Patent No. 6,243,720 (issued June 5, 2001) (hereinafter, "Munter'''). This rejection is 
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respectfully traversed. The analysis for overcoming the rejection is provided with respect to independent 

claim 4 and is similarly applicable to other claims that are subject to this rejection. 

The Examiner states: 

Referring to Claim 4, Munter teaches teaches: A routing method in a 
data processing system (routing product per col. 1 line 19-col. 3 line 52) 
receiving a packet (receives a packet with IP DA per col. 1 line 19-col. 3 line 
52.); 

retrieving the destination address from the data packet (IP DA used as a 
key in a hashing function consequently the destination address is retrieved from 
the data packet per col. 1 line 19- col. 3 line 52); 

hashing the destination address to determine a table index into a table in 
a computer readable medium (IP DA utilized in a hashing function per col. 2 line 
44-67. It would have been obvious to one of ordinary skill in the art at the time 
of the invention that a tables are implemented in software which is stored on a 
computer readable medium in order for the invention to work) 

reading a target address from a table entry using the table index (The 
network address associated with the next hop or target address is read from the 
table utilizing a index associated with a hash function in order to determine the 
location of the next hop per col. 1 lines 50-54), 

wherein the target address has been related to the stored in the table entry 
based on a computed value from a relation computation using the table index and 
the target address as operands in the relation computation (The examiner 
interprets this to mean that the next hop address is determined based upon 
hashing of the destination address in which a equivalent hash value is determined 
per col. 1 line 19-col. 3 line 52) 

modifying the data packet as a next-hop destination address (The next 
hop address is determined based upon the hashing function which outputs a index 
or target address which maps to the next hop address and is utilized to modify 
the, packet per col. 1 line 19-col. 2 line 52. The reference teaches that the packet 
is forwarded to the next output link per col. 1 lines 50-54. Forwarding of the data 
packet to the next hop inherently means that the data packet is modified to have 
the next target address in order for the packet to get to the destination.) 

transmitting the modified packet (The packet is transmitted to the next 
link per col.l lines 50-54) 

Munter does not expressly call for: a computer readable medium but 
teaches a routing table per col. 1 line 34. 

It would have been obvious to one of ordinary skill in the art at the time 
of the invention that a routing table is implemented in software which must be 
stored on a computer readable medium in order for the invention to work. 

Office Action dated December 29, 2004, pp. 3-4. 

The Examiner's Misinterpretation of the Claim Language is Unwarranted, and the Reference 
Does Not Teach or Suggest All the Features of Claim 4 

Claim 4 recites: 

4. A routing method in a data processing system comprising the 

steps of: 

receiving a data packet; 
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retrieving a destination address from the data packet; hashing the 
destination address to determine a table index into a table in a computer readable 
medium; 

reading a target address from a table entry using the table index, wherein 
the target address has been related to and stored in the table entry based on a 
computed value from a relation computation using the table index and the target 
address as operands in the relation computation; and 

modifying the data packet by storing the target address in the data packet 
as a next-hop destination address; and transmitting the modified data packet. 

Contrary to the examiner's belief, in the present case, each and every step in claim 4 is not taught 
or suggested in the cited reference. In particular, the steps of reading a target address and modifying the 
data packet are not shown or suggested in Munter as recited in claim 4. 

The examiner's interpretation of the reading step of claim 4 is incorrect. Specifically, the 
interpretation of the feature of "wherein the target address has been related to and stored in the table entry 
based on a computed value from a relation computation using the table index and target address as 
operands in the relation computation", (hereinafter, "wherein feature of claim 4") of the reading step is 
incorrect in that the examiner's interpretation omits specific features that are recited in the reading step. 

This wherein feature of claim 4 is similar to the wherein feature of claim 1 described above with 
reference to the rejection of claim 1 under § H2._The Examiner interprets this feature to mean, "the next 
hop address is determined based upon hashing of the destination address in which a [sic] equivalent hash 
value is determined" per a section in Munter. The Examiner cites the entire twenty-two paragraph long 
"Background of the invention" section from Munter as teaching or suggesting the wherein feature of 
claim 4. The examiner's incorrect interpretation is distinguished from the wherein feature of claim 4 first, 
followed by an analysis of the lengthy background section from Munter. 

A claim should be interpreted in view of the entire disclosure, including the specification. 
Phillips v. AWHCorp., 415 F.3d 1303, 1313 (Fed. Cir. 2005); Multiform Desiccants, Inc. v. Medzam, 
Ltd., 133 F.3d 1473, 1477 (Fed. Cir. 1998); Medrad, Inc. v. MRI Devices Corp., 401 F.3d 1313, 1319 
(Fed. Cir. 2005) ("We cannot look at the ordinary meaning of the term ... in a vacuum. Rather, we must 
look at the ordinary meaning in the context of the written description and the prosecution history."). 

For at least one description of the wherein feature of claim 4, consider the following section of 
the specification: 

The relationship between the targetMap entries and the targets is not 
necessarily a one-to-one relationship; each targetMap entry is associated or 
related to a single target, while a given target may be associated or related to 
more than one targetMap entry. 

The target to be associated with an entry in the targetMap table is based 
on a "nearness" calculation. For each index in the targetMap table, the index 
value is computed against each target identifier in the target set using nearness 
function 314. The nearness function receives as inputs: (1) a unique identifier 
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representing an entry within the targetMap, such as an array index or table index; 
and (2) a target identifier. The results of the nearness function computation 
produces a single, best value for a particular combination of the target identifier 
and the index position. 

Specification, pp. 16-17. 

This section of the specification provides at least one specific computation that supports the claim 
term "relation computation". The section further describes specific operands used in that computation 
that supports the operands recited in the claim. The section additionally describes a specific result 
obtained from the execution of the computation that provides support for the result recited in the claim. 

The wherein feature of claim 4 recites, "the target address has been related to and stored in the 
table entry". The Examiner interprets this feature to mean, "the next hop address is determined". There 
is no correlation between what the claim recites and what the examiner's interpretation is of the claim 
recitation. 

Next, the wherein feature of claim 4 recites, "based on a computed value from a relation 
computation". The Examiner interprets this feature to mean, "based upon hashing of the destination 
address". Considering that the specification provides full support and explanation of the claim term 
"relation computation", as described above, the examiner's interpretation unnecessarily and incorrectly 
generalizes the claim term relation computation. 

Next, the wherein feature of claim 4 recites, "using the table index and target address as operands 
in the relation computation". The Examiner interprets this feature to mean, "in which a [sic] equivalent 
hash value is determined". The examiner's interpretation does not account for specific operands in a 
specific computation, and again, unnecessarily and incorrectly generalizes the relation computation. 

Thus, in the specification section described above and other sections of the specification, 
sufficient information is provided so that guesswork can be avoided in interpreting the claim language 
during prosecution. Therefore, the examiner's generalizations and misinterpretation of the claim 
language are unwarranted under these circumstances. 

Now, having clarified the claim terms and the reading step of claim 4 in accordance with the 
specification, Munter does not teach or suggest the reading step in the twenty-two paragraph background 
section cited by the examiner, or the remainder of Munter 's disclosure. 

A prima facie case of obviousness is established when the teachings of the prior art itself suggest 
the claimed subject matter to a person of ordinary skill in the art. In re Bell, 991 F.2d 781 , 783, 26 
U.S.P.Q.2d 1529, 1531 (Fed. Cir. 1993). All limitations of the claimed invention must be considered 
when determining patentability. In re Lowry, 32 F.3d 1579, 1582, 32 U.S.P,Q.2d 1031, 1034 (Fed. Cir. 
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1994). In the case at hand, not all of the features of the claimed invention have been considered and the 
teachings of the references themselves do not suggest the claimed subject matter to a person of ordinary 
skill in the art. 

The section cited by the Examiner in support of the rejection is as follows: 

BACKGROUND OF THE INVENTION 
In data communication networks (Internet, ATM, Ethernet, token ring, 
and the like) address translation is an integral component of the system. In 
particular, there is a requirement of doing source and destination address 
lookups. 

Using the Internet as a basis for discussion, three main factors contribute 
to the speed of traffic over the Internet: link speeds, router data throughput, and 
packet forwarding rates. Readily available solutions exist for the first two factors. 
For example, fiber-optics can provide faster links and switching technology can 
be used to move packets through a router at gigabit speeds. The present invention 
deals with the third factor, packet forwarding. 

The most fundamental operation in any Internet Protocol (IP) routing 
product is the routing table search process. A packet is received with a specific 
destination address (DA), identified by a unique 32-bit field (in the current IP 
Version 4 implementation). The router must search a forwarding table using the 
IP DA as its key, and determine which entry in the table represents the best route 
for the packet to take in its journey across the network to its destination. 

The search is made complex by the fact that entries in the table have 
variable lengths, and also that many entries may represent valid routes to the 
same destination. Unlike a simple search that seeks to find an exact match within 
a table, the routing table search algorithm must select the most specific route 
from a number of entries, i.e. the route that represents the longest network prefix 
for the given DA. 

Specifically, a forwarding database in an IP router consists of a number 
of variable length network addresses. The length of the network address is given 
by a prefix length. When an IP router receives a packet, it must compute which 
of the network addresses in its database has the longest match when compared to 
the destination address in the packet. The packet is then forwarded to the output 
link associated with that prefix. 

For example, a forwarding database may have the following network 
addresses (NA) : NA 1 =0 1 0 1 , NA2=0 1 0 1 1 0 1 and NA3=0 1 0 1 1 0 1 0 1 0 1 1 . In this 
example the destination address is 1 6-bits long, the corresponding prefix mask 
values defines the network portion of the destination address: 
Pl = l 1 1 1000000000000, P2=l 1 1 1 1 1 1000000000 and P3=l 1111111111 10000. 
An address whose first 1 2 bits are 0 1 0 1 0 1 1 0 1 0 1 1 has longest matching prefix P 1 . 
An address whose first 12 bits are 0101 10101 101 has longest matching prefix P2. 

The route search operation is a very time-consuming operation, and 
typically defines the upper bound on the router's ability to forward packets. Many 
high speed routers augment the full-table search with a fast path process that 
performs an exact-match search in a small address cache, but must still default to 
the full-table search (the "slow path") for addresses not found in the cache. 

Routing problems are escalating in view of data links now operating 
routinely at 600 Mbits/s (OC-12) that can generate over 1 million packets-per- 
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second requiring routing. Further, new protocols, such as RSVP, require route 
selection based not only on destination address, but potentially also protocol 
number, source address, destination port and source port. 

In addition, virtual networks, quality of service (QoS) guarantees, and 
layer four snooping (i.e., deriving routing criteria from layer 4, TCP, UDP etc. 
fields) will tend to increase the number of bits needed to be considered. Further, 
IP version 6 will increase the size of the address filed from 32 bits to 128 bits, 
with network prefixes up to 64 bits in length. 

A popular algorithm used in routers is based on the Patricia Tree 
(Practical Algorithm to Retrieve Information Coded in Alphanumeric). The 
forwarding table that associates each prefix entry with an exit port and next-hop 
address is stored in a binary radix tree (BRT) form. The BRT is organized in a 
series of nodes, each of which contains a route of varying length, and each of 
which has two branches to subsequent nodes in the tree. At the ends of the 
branches are leaves, which either represent full 32-bit host routes (for devices 
attached directly to the router) or host-specific routes available to a particular 
subnet. 

For example, a traditional implementation of Patricia trees for routing 
lookup purposes uses 24 bytes for leaves and internal nodes. With 40,000 entries 
(in a typical routing table), the resulting tree structure alone is almost 2 Mbytes, 
and in a perfectly balanced tree 15 or 16 nodes must be traversed to find a routing 
entry. In some cases, due to the longest matching prefix rule, additional nodes 
need to be traversed to find the proper routing information as it is not guaranteed 
that the initial search will find the proper leaf. 

The Patricia Tree approach does not scale well to gigabit speeds. In 
particular, the data structure is too large and a worst-case lookup involves many 
memory accesses, taking far more time than is available to support gigabit rates. 

Hashing is an alternative approach to searching that is used in some LAN 
switches and has been applied to routing table searches. In contrast to the Patricia 
Tree, hashing operates strictly on an exact-match basis, and assumes the number 
of IP DAs that the system must handle at any one time is limited to a few 
thousand. A hash function is a sort of compression algorithm that is used to 
condense each 32-bit host route (i.e., exact DA) in the table to a smaller-sized 
entry (8-10 bits typically). 

Each host route maps to a unique location in a hash table, each entry in 
the hash table (termed a slot) corresponds to one or more host routes. The 
compression of hashing makes the table small enough to quickly search using 
simple hardware-based exact matching techniques. 

When a packet is received, an equivalent hash value is computed quickly 
from its DA, and compared directly against all entries in the hash table. When a 
match is found, an exact match of the DA can be searched in the list of addresses 
for the hash slot. If the address is not found in either search, there is no match, 
and the packet must be sent to a CPU for software processing-its address must 
also be used to compute a new entry for the hash table. 

The host-route hashing algorithm improves the average-case behaviour 
for small routing tables over the Patricia Tree. However, there continues to be a 
number of problems associated with host -route hashing. Since only host routes 
(i.e., full 32-bit addresses) are cached, the number of entries in the table grows 
linearly with the number of hosts on the network. This does not take advantage of 
the hierarchical address structure of IP, forcing tables to grow as rapidly as new 
users arrive on the Internet. 
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Another key disadvantage of storing host routes instead of network 
prefixes is the time required to update the routing table. Even a single network- 
level route change may require many host routes to be flushed from the table. 
This problem can be particularly severe for a very large hash table or in a 
backbone router, where multiple entries change after a routing update. 

A multi-stage lookup method using a compact routing table is described 
in Small Forwarding Tables for Fast Routing Lookups , Degermark et al., 
http://www.cdt.luth.se/net/publications.html. 

For the purpose of describing the small forwarding table data structure a 
representation of a binary tree 10 that spans the entire IP address space (Ipv4) is 
shown in FIG. 1. The height of the tree 10 is 32 bits, and the number of leaves is 
2.sup.32, one for each possible IP address. The prefix of a routing table entry 
defines a path in the tree ending in a node. All IP addresses (leaves) in the 
subtree rooted at that node should be routed according to that routing entry. In 
this manner each routing table entry defines a range of IP addresses with 
identical routing information. 

The forwarding table is a representation of the binary tree 10 spanned by 
all routing entries. This is called a prefix tree. The Degermark et al. data structure 
requires that the prefix tree be complete (i.e., that each node in the tree has either 
two or no children). A set of routing entries partitions the IP address into sets of 
IP addresses. 

The binary tree 10 of FIG. 1 illustrates the three levels (16-8-8) of the 
data structure proposed by Degermark et al. In particular, level one of the data 
structure covers the prefix tree down to depth 16, level two covers depths 17 to 
24, and level three depths 25-32. Wherever a part of the prefix tree extends below 
level 16, a level two section describes that part of the tree. Similarly, sections at 
level three describe parts of the prefix tree that are deeper than 24. The result of 
searching one level of the data structure is either an index into the next-hop table 
or an index into an array of sections for the next level. 

The Degermark et al. forwarding tables can be built during a single pass 
over all routing entries in a routing table. However, there is no guarantee that the 
resulting forwarding tables are memory optimized since the source data set (i.e. 
the routing entries) vary widely over different routers and over different times 
within the same router. 

Munter, Background of the Invention, col. 1,1. 19 - col. 3, 1. 52. 

In this section, Munter describes three existing methods used for searching routing tables, 
namely, the PATRICIA (Practical Algorithm To Retrieve Information Coded In Alphanumeric) tree 
lookup, the host-route hashing algorithm, and the multi-stage lookup method using small forwarding 
tables. The PATRICIA tree organizes routes of varying sizes to a destination in a binary radix tree. Each 
route in the binary radix tree is either a full route to a device attached to the router, or a host-specific route 
to the host's subnet. 

The host-route hashing algorithm hashes a destination address and stores a route to that hashed 
destination address in a hash table. A destination address of a data packet is hashed and matched to an 
exact hashed destination address entry in the hashed table. If an exact match is found, the data packet is 
routed to that address, otherwise the data packet is sent to the CPU for processing. 
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The multi-stage lookup using small forwarding tables uses a representation of the binary tree, as 
in PATRICIA tree lookup method. The forwarding trees are smaller binary trees that group routes to a 
range of IP addresses according to their IP prefix. The forwarding trees are themselves organized in a 
tree form. The multi-stage lookup proceeds from a prefix look up in one small forwarding tree, and 
proceeds down the subtree of that prefix until a route to a destination is found. 

Not only is the examiner's interpretation of the reading step of claim 4 incorrect, none of the 
methods described in the cited background section of Munter teaches or suggests the reading step of claim 
4 including the wherein feature of claim 4 . Each method described in the cited section is distinct from the 
method of reading a target address recited in claim 4. As can be seen from the cited section of Munter, a 
number of methods already exist for creating and searching routing tables. Each existing method is 
distinct from the other in the manner of creating the routing table and searching a destination address in 
that routing table. Claim 4 recites a method that is further distinct in the manner of creating the table and 
finding a target address in that table. 

Thus, when the underlying concepts of the various methods are principally distinct from the 
claimed method, as here, an existing method from the cited section of Munter does not teach or suggest 
the method recited in the claim. The remainder of Munter also fails to teach a method of creating a table 
and searching the table for a target address that resembles the reading step of claim 4. Therefore, Munter 
as a whole fails to teach or suggest the reading step of claim 4. 

Next, the Examiner makes a leap from the teaching and suggestions of the reference in order to 
reach the recitation of the modifying step of claim 4. The modifying step recites, "modifying the data 
packet by storing the target address in the data packet as a next-hop destination address". The Examiner 
states that the teaching in the cited background section " inherently means that the data packet is 
modified". How that inherency is supported by anything in Munter 's entire disclosure, the Examiner does 
not say. 

Simply asserting that something is inherent only puts one's opinion in the record, which opinion, 
in and of itself, is inconsequential as to the legal requirement of the standard of obviousness under 35 
U.S.C. § 103(a). For the assertion of inherency to count, the reference, or another evidence of knowledge 
common to those of ordinary skill in the art at the time of the invention, must support such assertion. 
Here, neither of those supports exists for the examiner's assertion of inherency. Therefore, without more, 
the modifying step of claim 4 is also not taught or suggested by Munter. Therefore, Munter fails to teach 
or suggest at least two steps, the reading step and the modifying step, of claim 4. Consequently, the 
Examiner has failed to established a prima facie case of obviousness against claim 4 under 35 U.S.C. § 
103(a). 
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Furthermore, independent claim 1 contains features similar to those in claim 4 and is also not 
made obvious by Munter by similar reasoning. As will be evident in the arguments overcoming the 
rejection of claim 9 under 35 U.S.C. § 103(a) below, the Examiner has conceded that the reading feature 
of claim 9 is not taught by Munter. Recall from the arguments above that the wherein feature of claim 9 
is similar to the wherein feature of claim 1 , and therefore similar to the wherein feature of claim 4, with 
one distinction. Therefore, the examiner's two assertions - that the wherein feature of claims 1 and 4 is 
taught by Munter, and that the wherein feature of claim 9 is not taught by Munter - are contradictory in 
nature. Taking the examiner's several assertions in the Office Action as a whole, a concession that 
Munter does not teach a feature in one claim should be applied to similar features in other claims as well. 
Therefore, the examiner's own statement as to the obviousness of claim 9 below, render the rejection of 
claims 1 and 4, based only on Munter, void. 

Claims 2-3 and 5-6 are also not made obvious by Munter at least by virtue of their dependence 
from one of these independent claims. Therefore, the rejection of claims 1-6 under 35 U.S.C. § 103(a) 
has been overcome. 

New claims 90-92 contain features similar to claims 4-6 and further clarify the term "relation 
computation" in accordance with the specification (Specification, p. 16, 11. 23-30; Figures 3A-3B). 
Therefore, claims 90-92 are also not obvious over Munter under 35 U.S.C. § 103(a). . 

III.B. As to claims 7-8 

The Examiner has rejected claims 7-8 under 35 U.S.C. § 103(a) as being unpatentable over 
Munter, in view of O'Connell et al, Integrated Data Table in a Network , United States Patent No. 
6,661,787 (issued December 3, 2003) (hereinafter, "O'Connell"). This rejection is respectfully traversed. 

The Examiner has rejected claims 7-8 stating: 

Claims 7-13, 15-24, 26-35, 37-46, 48-62, 64-78, 80-89 are rejected 
under 35 U.S.C. 103(a) as being unpatentable over Munter et. al. (US. Patent 
No.: 6,243,720 Bl) in view of O'Connell et. al. (U.S. Patent No.: 6,661,787) 

Referring to Claim 7, Munter teaches: A method in a data processing 
system for mapping a source identifier to a target identifier in a set of target 
identifiers (A method in a router or data processing system for mapping a DA 
address via hashing into a equivalent has value or target identifier per col. 1 line 
19-col. 3 line 52) the method comprising the steps of: 

Managing a data structure in a computer readable medium (A routing 
table which is software or a data structure per col. 1 line 19-col. 3 line 52. It 
would have been obvious to one or ordinary skill in the art at the time of the 
invention that the routing table is implemented in software which must be stored 
on a computer readable medium in order for the invention to work) 
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Hashing the source identifier to a location identifier of an entry in a data 
structure (Hashing a destination address or source identifier in order to hashing 
value or location identifier per col. 1 line 19-col. 3 line 52) 

Munter does not expressly call for: wherein the single target identifier is 
related to one or more entry locations 

Retrieving information associated with the target identifier from the 
entry in the data structure using the location identifier; 

And obtaining a mapped target identifier from the retrieved information 
associated with the target identifier 

Wherein the processing speed with which the source identifier is mapped 
to the mapped target identifier is independent of a total number of target 
identifiers in the set of target identifiers but teaches determining a next-hop 
address by utilizing a DA address and a hashing function per col. 1 line 19-col. 3 
line 52. 

O'Connell teaches: 

wherein the single target identifier is related to one or more entry 
locations (The pointer per Fig 3 relates to associated data which could relate to a 
plurality of values; such as, MAC, IP ,VLAN per Fig 2) 

Retrieving information associated with the target identifier from the 
entry in the data structure using the location identifier (The associated data per 
Fig 3 is retrieved based upon pointer or target identifier) 

And obtaining a mapped target identifier from the retrieved information 
associated with the target identifier (The pointers or target identifiers per Fig 3 
are mapped) 

Wherein the processing speed with which the source identifier is mapped 
to the mapped target identifier is independent of a total number of target 
identifiers in the set of target identifiers (The computation or determining a target 
identifier is made on a individual DA or source identifier basis therefore the 
processing speed is independent of the total number of target identifiers) 

It would have been obvious to one of ordinary skill in the art at the time 
of the invention to add the hashing b c t i o n of O'Connell to the router of 
Munter in order to reduce the storage requirements in order to perform routing 
functions per col. 2 lines 49-54 of O'Connell. 

Office Action dated December 29, 2004, pp. 5-7. 

The Combination of References Does Not Teach All The Features of Claims 7-8 

The Examiner has failed to state a prima facie obviousness rejection because the cited references 
used in proposed combination do not teach all of the features of claim 7 as believed by the examiner. 
Claim 7 recites: 

7. A method in a data processing system for mapping a source 
identifier to a target identifier in a set of target identifiers, the method comprising 
the steps of: 

managing a data structure in a computer readable medium, wherein each 
entry within the data structure stores information associated with a single target 
identifier and wherein a single target identifier is related to one or more entry 
locations; 
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hashing the source identifier to a location identifier of an entry in the 
data structure; 

retrieving information associated with the target identifier from the entry 
in the data structure using the location identifier; 

obtaining a mapped target identifier from the retrieved information 
associated with the target identifier, and 

wherein a processing speed with which the source identifier is mapped to 
the mapped target identifier is independent of a total number of target identifiers 
in the set of target identifiers. 

Contrary to the examiner's assertion, Munter in view of O 'Connell, does not teach or suggest at 
least the managing step of claim 7. Particularly in the managing step, the combination of cited references 
fails to teach, "wherein a single target identifier is related to one or more entry locations". 

The Examiner concedes that Munter fails to teach this wherein feature of the managing step of 
claim 7. The Examiner cites to the following Figure of O 'Connell to find support for the rejection of this 




Jl I T 

O' Connell, Figure 3. 

In this Figure O 'Connell, teaches that an entry in table 32, such as "pointer (13:0) could point to a 
L2/L3 associated data. L2/L3 associated data is described by O 'Connell as follows: 
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If an entry in table 9 is a unicast entry (as shown in simplified form in 
FIG. 3), it may be defined as follows: 

Bit 127 is unused. Bits 126:79 are a MAC address. Bits 78:47 are an IP 
address. Bits 47:39 are a VLAN number. Bits 38:34 are a destination port 
number. Bit 33 is an age bit. Bit 32 is a 'perm' bit. Bits 31:28 are miscellaneous 
utility bits. Bits 27:14 constitute a layer 3 link pointer (to the next entry in a 
chain). Bits 13:0 constitute a layer 2 link pointer. The use of link pointers in 
tables accessed by way of a hashing process is well known and need not be 
described in detail. 

The table 9 may also support a multicast entry which may be defined as 

follows: 

Bits 127:101 are unused. Bits 100:54 constitute a MAC address. Bits 
53:46 constitute a VLAN address. Bit 45 is an age bit. Bit 44 is a 'perm' bit. Bits 
43:18 are a destination bit mask. Bits 17:14 are miscellaneous utility bits. Bits 
13:0 constitute a layer 2 link pointer. 

O'Connell, col. 4, 11.37-54. 

This section of O 'Connell describes two variations of a 128 bit data that can be stored in the table 
marked reference numeral 9 in the cited Figure. Note that the L2/L3 associated data is a single 128 bit 
data entry of which several bit segments are described to contain certain pieces of information. Also note 
that each entry of table marked by reference numeral 32 points to exactly one L2/L3 associated data. 
O 'Connell shows in Figure 3 that an entry in table 32 can be hashed from a variety of information; 
however, only one hash value computed from one of the possible variation of information is stored in an 
entry in table 32 at any given time. Thus, O'Connell 's Figure 3 and corresponding disclosure teaches that 
one entry in table 32, the entry generated in one of several different ways, corresponds with one entry in 
table 9, the entry containing 128 bits of information. This teaching in O'Connell does not teach or 
suggest the wherein feature of the managing step as recited in claim 7. 

Claim 7 recites, "a single target identifier is related to one or more entry locations". Thus, for the 
sake of comparison, claim 7's recitation corresponds to one L2/L3 associated data associated with several 
table 32 entries in O 'Connell. O 'Connell does not teach such an association, nor does O 'ConnelVs entire 
disclosure suggest a capability for making such an association, or any utility thereof. 

The Examiner has made two misinterpretations as to this feature of claim 7. First, capability to 
generate a table 32 entry from several different pieces of information does not teach several entries in 
O 'Connell 's table 32. Regardless of how generated, O 'Connell 's table 32 contains only one entry for the 
data packet. In contrast, claim 7 recites several entries in the table. 

Second, the wherein feature of the managing step of claim 7 recites, "related to". As described in 
the above sections, the claim term "related to" cannot be interpreted in vacuum and without context of the 
disclosure. The specification provides specific meaning for the term "related to" as described with 
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respect to claims 1, 4, and 9 above. Thus, O'Connell's association of an entry in table 32 to an entry in 
table 9 does not teach or suggest, "a single target identifier is related to one or more entry locations" as 
recited in claim 7. 

For at least these reasons, O'Connell fails to teach or suggest the managing feature of claim 7. 
Therefore, the combination of Munter and O'Connell fails to teach or suggest all the features of claim 7. 
Consequently, the rejection of claims 7-8 under 35 U.S.C. § 103(a) has been overcome. 

III.C. As to claims 9-13. 15-24. 26-35, 37-46, 48-62. 64-78, and 80-89 

The Examiner has rejected claims 9-13, 15-24, 26-35, 37-46, 48-62, 64-78, and 80-89 under 35 
U.S.C. § 103(a) as being unpatentable over Munter, in view of O'Connell. This rejection is respectfully 
traversed. 

The Examiner has rejected claims 9-13, 15-24, 26-35, 37-46, 48-62, 64-78, and 80-89 stating: 

Referring to Claim 9, Munter reaches a method in a data processing 
system for mapping a source identifier to a target identifier (A method in a router 
or data processing system for mapping a DA address via hashing into a 
equivalent has value or target identifier per col. 1 line 19-col. 3 line 52) the 
method comprising the steps of: 

Hashing the source identifier to determine a table index into a table in a 
computer readable medium (Hashing a DA address or source identifier into a 
equivalent hashing value or target identifier in a table per col. 1 line 19-col. 3 line 
52. It would have been obvious to one or ordinary skill in the art at the time of 
the invention that the routing table is implemented in software which must be 
stored on a computer readable medium in order for the invention to work.) 

Munter does not expressly call for: 

Reading the target identifier from a table entry using the table index, 

Wherein the target identifier has been related to and stored in the table 
entry based on a computed value from a relation computation using the table 
index and the target identifier as operands in the relation computation but teaches 
determining a next-hop address by utilizing a DA address and a hashing function 
per col. 1 line 19-col. 3 line 52.) 

O'Connell teaches: reading a target address from a table entry using the 
table index (Reading a Pointer or target address which is stored in a table based 
upon a 1 5 bit index per Fig 3), 

wherein the target address has been related to and stored in the table 
entry based on a computed value from a relation computation using the table 
index and the target address as operands in the relation computation (The 
applicant broadly claims that the target address is determined based upon a 
relationship between the target address and index. The examiner believes that 
the applicant is really trying to say that the target object is determined based upon 
a relationship between the target address and target index because there is no 
support in the specification for target address to be computed based upon a 
relationship between the target address and target index. The examiner interprets 
the associated data or target object has been determined based a relationship 
between the pointer or target address and 15 bit or index. 



Page 41 of 44 
Conner et al. - 09/657,1 19 



It would have been obvious to one of ordinary skill in the art at the time 
of the invention to add the hashing function of O'Connell to the router of Munter 
in order to reduce the storage requirements in order to perform rouging per col. 2 
lines 49-54 of O'Connell. 

Office Action dated December 29, 2004, pp. 7-8. 

The Combination of References Does Not Teach All The Features of Claims 9-13, 15-24. 26-35. 
37-46. 48-62. 64-78. and 80-89 

The Examiner has failed to state a prima facie obviousness rejection because the cited references 
used in proposed combination do not teach all of the features of claim 9 as believed by the examiner. 

Claim 9 has been previously quoted in response to the rejection of claim 9 under § 1 12. The 
claim is not quoted again for the sake of brevity. 

Contrary to the examiner's assertion, Munter in view of O'Connell does not teach or suggest at 
least the reading step of claim 9. Particularly in the reading step, the combination of cited references fails 
to teach the wherein feature of claim 9 previously described in response to the rejection of claim 9 under 
§112. 

As explained there, the wherein feature of claim 9 differs from the wherein feature of claim 1 in 
that where the wherein feature of claim 1 recites "target address " the wherein feature of claim 9 recites 
"target identifier ". Therefore, the same section of the specification described above lends full support to 
the wherein feature of claim 9 as well in the manner described above. Furthermore, that section of the 
specification specifically provides that an entry could contain "a target identifier", providing additional 
support the distinction between the wherein feature of claim 9 and the wherein feature of claim 1 . 

In the obviousness rejection of claim 9, the Examiner makes similar misinterpretations of the 
wherein feature of claim 9 as was the case in the rejection of claim 9 under § 1 12. By the reasoning 
advanced there, the examiner's interpretation of the claim language is incorrect. 

Now, the Examiner concedes that Munter does not teach even the misinterpreted version of the 
wherein feature of claim 9. The Examiner cites to O 'Connell Figure 3, reproduced and described above, 
to find a teaching or suggestion of the misinterpreted wherein feature of claim 9. First, O 'Connell Figure 
3 does not teach or suggest even the misinterpretation of the wherein feature of claim 9. Second, even if 
it does, that teaching still fails to teach or suggest the wherein feature of claim 9 in the manner recited. 
Therefore, the combination of Munter and O 'Connell fails to teach or suggest all the features of claim 9 
under 35 U.S.C. § 103(a). 

Independent claims 20, 21, 42, 58, and 74 contain features similar to those in claim 9, and are 
also not made obvious by similar reasoning as above. Dependent claims 10-13, 15-19, 21-24, 26-30, 32- 
35, 37-41, 43-46, 48-57, 59-62, 64-73, 75-78, and 80-89 are also not made obvious at least by virtue of 
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their dependence from one of these independent claims. Therefore, the rejection of claims 9-13, 15-24, 
26-35, 37-46, 48-62, 64-78, and 80-86 under 35 U.S.C. § 103(a) has been overcome. The rejection of 
claims 87-89 is moo tin view of the cancellation of those claims. 

IV. Objection to Claims 

The Examiner has stated that claims 1-89 were objected to for being inconsistent with the 
specification and confusing. This object should be withdrawn. 
The Examiner states: 

Claims 1-89 are objected to because of the following informalities: 

Referring to Claims 1 & 4, the examiner objects to the limitations 
"wherein the target address has been related to and stored in the table entry based 
on a computer value from a relation computation using the table index and the 
target address as operands in the relation computation; and modifying means for 
modifying the data packet by storing the target address in the data packet as a 
next -hop destination address" because this limitation is inconsistent with the 
specification as well as confusing. 

The specification discloses that the target object can be determined based 
upon a computed or mathematical relationship between the target index and the 
target identifier or in other words target object=mathematical relation (SID, 
index, target id) on Pg 7 line 1-Pg 8 line 15. 

The specification provides written support that the target id can be 
determined based upon a computed or mathematical relationship with the SID 
and target index or in other words target id-elation (SID, index) per Pg 2 line 20- 
Pg 3 line 24. 

The applicant has claimed target address=mathematical relation (target 
address, target index) which is not defined in the specification. 

The examiner suggest that the applicant change target address to target 
object and state that the target object is computed based upon a relationship with 
(SID or destination address and target index) 

Referring to Claims 9, 20, 31, 42, 58, & 74, the examiner objects to the 
limitation "wherein the target identified has been related to and stored in the table 
entry based on a computed value from a relation computation using the table 
index and the target identifier as operands in the relation computation" because 
this limitation is confusing and is not disclosed by the specification. 

The specification discloses that the target object can be determined based 
upon a computed or mathematical relationship between the target index and the 
target identifier or in other words target object=mathematical relation (SID, 
index, target id) on Pg 7 line 1-Pg 8 line 15. 

The specification discloses that the target id can be determined based 
upon a computed or mathematical relationship with the SID and target index or 
in other words target id=relation (SID, index) per Pg 2 line 20-Pg 3 line 24. 

The applicant has claimed target identifier = mathematical relation 
(target id, table index) which is not defined in the specification. 

The examiner suggests that the applicant define the relationship for target 
identifier based upon SID, and target index. 

Office Action dated December 29, 2004, pp. 15-16. 
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In view of the reasoning and support described above in response to the rejections under 35 
U.S.C. § 1 12, first and second paragraphs, claims 1-6 and 9-89 are not inconsistent with the specification. 
The claims are clear with respect to the specification at least in the sense that the claims recite features 
described in the specification and arranged according to the claimed invention. Claims 7-8 are objected 
to but nothing in those claims is particularly pointed out as objectionable. Therefore, the objection as to 
claims 1 -89 should be withdrawn. 

As to the objection to dependent claims 18, 29, 40, 56, 72, and 88, the examiner's attention is 
directed to section I.E of this response. In view of the description in that section, the objection to these 
claims should be withdrawn. 

As to the objection to dependent claims 19, 30, 41, 57, 73, and 89, the examiner's attention is 
directed to section I.F of this response. In view of the description in that section, the objection to these 
claims should be withdrawn. 

V. Conclusion 

It is respectfully urged that the subject application is patentable over Munter and O'Connell and 
is now in condition for allowance. 

The Examiner is invited to call the undersigned at the below-listed telephone number if in the 
opinion of the Examiner such a telephone conference would expedite or aid the prosecution and 
examination of this application. 

DATE: A pril 2, 2007 

Respectfully submitted, 

/Rakesh Garg/ 

Rakesh Garg 
Reg. No. 57,434 
Yee & Associates, P.C. 
P.O. Box 802333 
Dallas, TX 75380 
(972) 385-8777 
Agent for Applicants 
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